La primera revista de PC para los desarrolladores de videojuegos 



Universal Music en la Web 

P or fin podemos disfrutar en la web de la discográfica que trae hasta nosotros la música 
de artistas de la talla de Raimundo Amador, Lucrecia, Blues Brothers 2000, Molotov o 
Aqua. Dentro de las páginas de esta compañía aparecen apartados como artistas, 
lanzamientos, noticias, giras, etc. Mención especial merece el canal de comunicación 
interactiva, con secciones como Top 5, una lista de éxitos confecciona con ios votos de los 
visitantes, o )ukeBox, en la que se pueden escuchar on-tine los éxitos de la compañía. Icón 
Medialab ha sido la encargada de asesorar a Universal Music en este terreno. 


Llega o Barcelona la feria multimedia electrónica más 
importante de Europa 

L as empresas MDI y Dream Comunicación han 
llegado a un acuerdo para celebrar en Barcelona 
(España) la feria del grafismo, producción y 
multimedia electrónica más importante de Europa, el 
CCIX. La importancia de este evento es comparable a 
la celebración de la feria Siggraph en los Estados 
Unidos, 

Del 2 al ó de febrero de 1999, la Feria de Barcelona, 
situada muy cerca del aeropuerto, acogerá a las 
compañías más importantes en animación, diseño 
gráfico, frroodajsf, multimedia e Internet para que 
muestren sus nuevos productos e innovaciones. Para 
coordinar la CGiX de Barcelona, la empresa Dream 
Comunicación ha sido escogida Agente Oficial para 
España por la compañía MDI, organizadora del 
evento. La función de Dream Comunicación será la 
organización del Pabellón Español que reunirá a las empresas más destacadas del sector. 
En este sentido, Dream Comunicación se encargará de la coordinación del alquiler del 
espacio y de ios stands , En sus manos también estará la organización de las diferentes 
conferencias y la realización de la cobertura del evento a través de una web y de un 
diario bilingües {inglés/español). 

Para realizar la cobertura informativa del evento, Dream Comunicación desplazará su 
redacción al centro del CGIX. Periodistas, fotógrafos, cámaras de vídeo... La finalidad 
será realizar "in si tu" una web y un diario que recoja las presentaciones más 
importantes, las entrevistas más interesantes y los datos más relevantes de este 
acontecimiento. 

La última edición de la CGIX se celebró en Amsterdam (Holanda) en enero de este año. 
Según una encuesta realizada entre los más de cinco mil visitantes profesionales que 
asistieron, un 80 por ciento declaró que tenían intención de compra a realizar entre ó y 
12 meses. A medida que se vayan acercando las fechas de celebración del CGIX de 
Barcelona, se irán conociendo los periodos de inscripción y precios, así como todas las 
novedades que se produzcan. 




Suman 


• 3D Manía.2 

Sumérgete de lleno en el mundo de la programación 
3D de la mano de uno de los gurús españoles, 

•DIV .5 

Nuestro curso te muestra todas las claves del mejor 
entorno para realizar un juego de ordenador. 

• Curso Direct X.3 

Todos los trucos y técnicas para dominar las más 
populares librerías de Microsoft. 

• Taller 20.13 

Te mostramos el diseño y la optimización de 
páginas web. 


Nfldge Nefuiorks anuncio un 
paquele de producios Token Ring 

E ste suministrador internacional de soluciones de 
redes presenta un paquete de producto Token 
Ring de alta velocidad de 100 Mbps, con todas las 
funcionalidades basados en estándares. La nueva serie 
de productos, que permite desarrollar HSTR en todas 
las redes, incluye el adaptador Madge Smart 
100/16/4 PCI-HS Ringnode. Se trata de una tarjeta de 
interfaz de redes que permite la ampliación a 4,16 o 
100 Mbps; soporta, además, la detección y selección 
automática de velocidades y tipos de cables, de forma 
que se adapta a cualquier entorno sin necesidad de 
reconfigurar el equipo. También ofrecen módulos 
HSTR de fibra de dos puertos y de cobre de cuatro 
puertos para la familia Smart Ringswitch de 
conmutadores Token Ring. Por otra parte, los precios 
a los que aparecerá la serie al mercado serán 
agresivos, de modo que serán bastante asequibles. 
Madge se convierte de esta manera en el primer 
fabricante que nos presenta aplicaciones de redes 
troncales Token Ring de 100 Mbps. Las primeras 
unidades que se encuentren disponibles serán para el 
conmutador Smart Ringswitch Express y para el 
conmutador Smart Ringswitch Plus de alta capacidad, 
en sus versiones de cobre o fibra. 




En nuestra CD-Rom de portada incluimos el siguiente material; 

* Los códigos fuentes de los ejemplos comentados en el articulo 3D Manía 

* GIF Mouie Gear 2.5: Una herramienta que sirve para manejar imágenes. 

* Anarkano: Un excelente ejemplo de videojuego de programación sencilla. 
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Bump Mapping 


Este mes comenzamos una serie de artículos 
donde descubriremos la técnica Bump-Mapping, 
muy utilizada en escenas 3D para simular 
relieve en los polígonos. 


U no de los principales problemas con los 
que se encuentran tanto diseñadores 
como grafistas es que el número de polígonos 
que se pueden emplear para una escena está 
siempre muy limitado por el hardware. Hemos 
de recordar que estamos diseñando mallas que 
van a ser empleadas en programas que 
trabajan en tiempo real. Por tanto no podemos 
emplear cualquier número de polígonos como 
haríamos en una producción cinematografíes. 
Generalmente el grafista siempre requiere un 
número mayor de polígonos que el permitido, 
mientras que el programador siempre intenta 
reducir la complejidad poligonal a toda costa 
para conseguir acelerar al máximo el engine. 
Esta es la eterna dispusta entre programadores 
y grafistas. Esta situación ocurre especialmente 
en programas que deben «renderizar» en 
tiempo real, como por ejemplo la 
programación de videojuegos, tema al que nos 
referimos habitualmente en esta sección. La 
cosa se complica aun más si nos situamos en 
un ordenador personal. Hay que reconocer 
que con las tarjetas aceleradoras 30 la calidad 
ha subido mucho en el último año pero, aun 
así, nos encontramos ante una falta de recursos 
y de máquina para poder mover la escena de 
nuestros sueños en tiempo real. 

Figura 1. Esta es la textura a la que queremos dar 
relieve. Vamos a relacionar el color de cada pIxel 
con su altura relativa. Esta altura sera la que 

DETERMINE EL RELIEVE DEL MAPA. 



Generalmente gran parte de los polígonos 
tienen que ser empleados en dar la forma 
principal al objeto mientras que el modelado de 
los detalles se descuida a menudo recurriendo al 
empleo de texturas que suelen enmascarar 
bastante bien esta deficiencia. Así, por ejemplo, 
el diseño poligonal del relieve de una pared de 
mármol es absolutamente impensable. La 
solución habitual es emplear una textura de 
mármol que generalmente cumple bien su 
misión. Del mismo modo, los ladrillos de una 
pared suelen realizarse a base de textura; es 
impensable modelar por polígonos estos 
aspectos. Pero si somos un poco más 
ambiciosos podremos conseguir el deseado 
detalle sin gastar un número adicional de 
polígonos. La solución se llama Bump-Mapping, 
Cuando nos referimos a detalle, queremos decir 
que los algoritmos de iluminación tendrán un 
comportamiento similar al que producida una 
malla de polígonos equivalente. Bump-Mapping 
no es más que «truco» que mediante el empleo 
de varias texturas simula variaciones de 
normales dentro de un mismo polígono. Pero 
vayamos por partes. 

El hardware limita en 
gran medida el número de 
polígonos por pantalla. 

Por ello se simulan los relieves 

Hemos preferido tratar esta técnica con detalle 
y tranquilidad para que el lector entienda 
perfectamente el funcionamiento. Vamos a 
dedicar más de un artículo para mostrar el 
funcionamiento, así como diversas utilidades 
de esta habitual técnica. 

El objetivo de estos artículos es claro: dotar a 
nuestro motor de la capacidad de mostrar 
texturas con Relieve o Bump (en polígonos 
tridimensionales). Eso es ¡o que conseguiremos 
al acabar la serie de artículos sobre este tema. 
En este primer artículo pondremos límites al 
problema y vamos a buscar solución para 
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Bump-Mapping en 2 dimensiones. Una 
correcta compresión de este artículo es la clave 
para comprender el Bump 3D, que no es más 
que una mera extensión (caso similar a cuando 
explicamos el Clippinq, primero en polígonos 
2D y luego en 3D). 

BUMP-MAPPING 2D 

En este apartado nos vamos a limitar únicamente 
a las dos dimensiones. Así, nos olvidamos de los 
polígonos, de las cámaras, matrices, etc. 
Tendremos una textura (un fichero TCA, por 
ejemplo) en pantalla a la que cambiaremos de 
relieve. Vamos a trabajar por ejemplo con el 
dibujo que aparece en la Figura 1. 

Queremos conseguir que los bultos que 
aparecen en el dibujo creen una sensación de 
relieve. Del mismo modo, las letras deben 
poseer un relieve propio para que resalten y 
se puedan leer. 

Para almacenar estos datos empleamos lo que 
se denomina un mapa de alturas. Un mapa de 
alturas es similar a un bítmap, pero en vez de 
almacenar el color en cada posición 
almacenamos la altura de cada posición. Así, si 
por ejemplo empleamos alturas de 8 bits (lo 
cual suele ser suficiente), un valor de O indica 
mínima altura mientras que el valor 255 indica 
la máxima altura. Por supuesto todos estos 
convenios son arbitrarios. Lo importante es 
que seamos coherentes a lo largo de todo el 
proceso con las decisiones que tomemos 
inicialmente. Éstos son los valores que vamos a 
emplear para crear el relieve. Una zona donde 
todos las posiciones tengan la misma altura no 
deberá mostrar relieve mientras que una zona 
con muchas variaciones deberá dar sensación 
de rugosidad. Del mismo modo deberemos 
tener en cuenta la variación de nivel de una 
posición con respecto a sus vecinos. Vamos a 
considerar los vecinos de una posición a las 
casillas que tenemos a los lados derecho, 
izquierdo, superior e inferior. No tenemos en 
cuenta los vecinos de las diagonales. 

¿Cómo construir el mapa de alturas? No suele 
ser muy difícil a partir de la imagen a la que 
queremos aplicar el relieve. Normalmente, 
tomando el color como la altura suele 
funcionar (en imágenes con paleta si nuestro 
altura es de 8 bits). Así, nuestro mapa de 
alturas quedaría de un modo similar a la figura 
1, si interpretamos que el color negro es la 
altura O y el color blanco la altura máxima. 









3D Manía 


A veces puede ser necesario que el mapa de 
alturas y el dibujo que queremos iluminar sean 
distintos. En ese caso emplearemos dos 
texturas distintas. Veremos este caso cuando 
tratemos el Bump Mapptng en 30. 

El siguiente paso es la construcción de ío que 
se denomina el mapa de luz. El «mapa de luz» 
es otro bitmap que representa el foco de luz 
con el que vamos a iluminar nuestro relieve. 
Para ello empleamos una textura True-Cotor 
(por ejemplo) con cualquier forma y cualquier 
color. Lo que realmente se va a pintar en 
pantalla son pixels de! mapa de luz, por lo que 
su color y forma va a determinar la imagen 
final del efecto. Para nuestro ejemplo, vamos a 
emplear una luz circular blanca como la que 
aparece en la figura 2* 

Podemos considerar este mapa de luz como e! 
equivalente a las texturas de entorno que 
empleamos en el último artículo para simular 
Phong* De hecho el enviroment-mapping jugará 
un papel importante en el Bump 3D* 

Con esto ya tenemos todo lo necesario para 
crear nuestro efecto* Supongamos ahora que 
empleamos un mapa de alturas cuyas alturas 
son todas O * La imagen que deberíamos 
obtener sería la de la figura 2, es decir, el mapa 
de luz original, debido a que no existe ningún 
desnivel que altere el mapa de luz. Según van 
apareciendo relieves en forma de bultos el 
dibujo de la figura 2 debe perturbarse 
ligeramente para crear esa sensación de relieve. 
Precisamente en eso consiste la tánica de 
Bump-lvlapping. Tenemos que introducir 
perturbaciones en nuestro mapa de luz para 
crear el efecto de relieve* Entendemos por 
«pertubación» un desplazamiento en las 
coordenadas del mapa de luz: si por ejemplo 
tuviéramos que pintar ei píxe! del mapa de luz 
<50,50> una perturbación nos podría obligar a 
pintar el <55,55>, que tendría una iluminación 
distinta. La perturbación debe poder ocurrir 
tanto horizontal como verticalmente y en 
ambos sentidos. 

¿Cómo calcular la perturbación? Una buena 
idea es considerar e! mapa de alturas como 
una gráfica XY y calcular la tangente en el eje 
X y en el eje Y en cada punto del mapa de 
alturas. Podemos calcular la tangente 
mediante la derivada. Una buena 
aproximación de la derivada: 

Dx = Vecino Izquierdo - Vecino Derecho 

Dy = Vecino Superior - Vecino Inferior 

La derivada nos da una medida de la pendiente 
del punto con respecto a su vecindad* Con esta 
pendiente podemos perturbar el mapa de luz 
correctamente y conseguir el efecto deseado. A 
veces es buena ¡dea multiplicar dxydy por algún 
factor para escalar la pendiente. Por tanto dxy 



Figura 2. El mapa de luz, muy similar al que 

EMPLEAMOS EN LA TÉCNICA DE ENVIROMENT-MAPPING 
PARA SIMULAR PHONG. 


dy [números con signo] representan la 
pertubarción que aplicar en esa posición. Dx 
representa la perturbación horizontal mientras 
que Dy representa la perturbación vertical* 
Ambas perturbaciones con signo* 

Pongamos el siguiente ejemplo: supongamos 
que en un punto de pantalla corresponde 
iluminar con la posición <50,50> del mapa de 
luz* Este punto posee unos valores de dx=-5 y 
dy^l. Por tanto, el valor real que debemos copiar 
en pantalla es el <50+dx,50+dy> - <45,57x 
Con esta sencilla operación podemos 
conseguir el efecto de relieve deseado* En la 
figura 3 tenemos el efecto final que 
conseguimos aplicando BumpMapping 2D. 

Para comprender plenamente 
el BumpMapping 3D 
hay que empezar por 
analizar el 2D 

Es increíble la calidad gráfica que se consigue 
con un algoritmo tan sencillo. Recomiendo al 
lector que ejecute ahora mismo el ejemplo que 
viene en el CD-Rom que acompaña a ia revista 
para que pueda apreciar ia calidad del 
resultado obtenido. Pasamos ahora mismo a 
describir con detalle los pasos llevados a cabo 
para construir dicho ejemplo. 

EL EJEMPLO DE ESTE MES 

Como todos los meses, con cada artículo 
encontramos su correspondiente ejemplo. Este 
mes hemos desarrollado un ejemplo bastante 
completo y hemos intentado sacar ei máximo 
partido a las rutinas de iectura de TGAs que 
desarrollamos hace 2 artículos. 

Nuestro objetivo en el ejemplo de este 
artículo es mostrar un efecto Bump¬ 
Mapping que funcione en ventana y a 
resoluciones de 15-16-24-32 bpp. Con la 


LISTAD01 

void draw_bump(SDWORD x, SDWORD y 
BYTE *light, BYTE *bump, 

BYTE *vid, BYTE bytespp) { 

H Parámetros de la función: 

//- x,y posición de la esquina superior 
izquierda del mapa de luz 
H - light: mapa de luz 
H - bump : mapa de alturas 
H- vid : puntero o pantalla 

//- bytespp: Bytes por pixel : 15,16,24,32 

D WORD preX,preY,preXvid,preYvid; 
SDWORD i,j; 

SDWORD xlen,ylen; 

DWORD cvid,dight; 

SDWORD dx,dy; 

DWORD up,down,left,right; 

H Ciipping del mapa de luz 

preX=x<0?-x:0; 

preY=y<0?-y:0; 

if(x<0) preXvid=0; 
else preXvicf=x; 

¡f(y<0) preYv¡d=0; 
else preYvid=y; 

if(x+UGHT_XSIZE>XRES) xlen=XRES- 
preXvid; 

else xlen=x+UCHT_XSIZE-preXv¡d; 

i((y+UGHT_YSIZE>YRES) ylen=YRES- 
preYvid; 

else ylen=y+LIGHTJSIZE-preYvid; 

cvid=preYv¡d*XRES + preXvid; 
clight=preY*UGHT_XSIZE + preX; 


flexibilidad que dimos a nuestro cargador 
de texturas, esto no va a ser ningún 
problema. Así pues, nuestro primer paso 
consiste en reservar memoria, cargar las 
texturas y convertirlas al modo de vídeo 
actual. Debemos tener en cuenta que el 
mapa de alturas es realmente una textura 
con paleta. Podemos ignorar la paleta, pues 
en este caso no nos interesa su contenido. 

light=(BYTE 

*)malloc(headi.width*headi.height*bytespp); 

bump=(BYTE 

*)malloc(headB. width *headB. heigbt*s¡zeof(BYTE) 
+256*4); 
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readjga_picture("Ught.Tga", light, 
headL.width, headL.height, &gfx); 

read_tga_map("bmp2d.tga" l bump, bump + 
XRES*YRES, head8.width, 
headB.heigbt); 

Queríamos añadir al programa algo de 
interactividad, así que incluimos la opción de 
mover el foco de luz con las teclas de los 
cursores, lo que además servía para poder 
apreciar mejor el efecto de relieve. Este 
añadido traía un problema: la necesidad de 
realizar el recorte del mapa de luz. Pero esto 
no es ningún problema, como vimos en 
nuestro artículo sobre Clipping 2D. Nosotros 
hemos empleado un mapa de luz de 512x512 
sobre una ventana de 320x240 (todos estos 
parámetros pueden ser variados fácilmente en 
el código). El código encargado de realizar el 
clipping 2D aparece en el listado 1. 

Una vez tenemos los valores necesarios 
obtenidos del clipping 2D del mapa de luz 
recorremos los píxels de pantalla y en cada 
uno de ellos calculamos las perturbaciones 

LISTADO 2 

case 2: //J 5,16 bpp 

for(i=0;i<ylen;i++,cvid+-XRES, dight-c-S I 2) 

for(j=0;j<x!en;j++) { 

if(cvtd+j==0) left=cvid+j; 
else left=cvid+j-1; 

¡f(cvid+j==XRES*YRES-l) 

right=cvid+j; 

eke r¡ght=cvid+j+1; 

if(cv¡d+j<XRES) up=cvid+j; 
else up=cvid+j-XRES; 

if(cvid+j>=XRES*YRESXRES) 

down=cvid+j; 

else down-cvid+j+XRES; 

dx=*(bump+leñ) - *(bump+right); 
dy=*(bump+up) - *(bump+down); 

*(wv¡d+cvid+j)=*(wlight+ 

((dight+j+dx+dy*LiGHT_XSIZE)&262143)); 

¡ 


break; 

I! Aquí vienen los casos de 24 y 32 bpp 


Pnrpamación 


horizontales y verticales como hemos 
explicado más arriba. El inconveniente que 
encontramos aquí viene dado por los posibles 
desbordamientos que se pueden producir, por 
ejemplo al acceder al vecino izquierdo de la 
posición <0,0> (acceso a memoria prohibida) 
o de cualquier posición que se encuentre en 
<0, y>0 > (cálculo de la pendiente incorrecto). 
Con el objetivo de no relentizar mucho el 
efecto, nos preocupamos únicamente de no 
acceder a posiciones de memoria prohibidas 
descuidando el cálculo de las perturbaciones 
en los bordes del mapa. Al aplicar la 
perturbarción obtenemos un problema 
similar, esta vez con el mapa de alturas. De 
nuevo nos preocupamos únicamente de no 
realizar accesos a memoria que puedan 
provocar una excepción de página. Todo ello 
aparece claramente en el listado 2, que 
muestra el «loop» principal para el modo de 
vídeo de 15/16 bpp. 

Hat qye destacar el empleo de la máscara 
262143 usado en el Acceso al mapa de luz. 
Con esto nos aseguramos que no estamos 
leyendo fuera de la región 512x512. El 
empleo de texturas cuadradas y con 
dimensiones que son potencias de dos suelen 
ser muy útiles en estos casos. 

El propio usuario es el 
que debe jugar con los valares 
y observar los distintos 
resultados que puede obtener 

Para los casos de 24 y 32 bpp el código es 
similar. Así, por ejemplo, para 24 bpp 
realizamos 3 escrituras a memoria de vídeo: 
una para la componente roja, otra para la 
verde y otra para la azul. Esto es más rápido 
que realizar una escritura de WORD (2 bytes) 
y otra de BVTE, pues generalmente la 
escritura de WORD estará desalineada. 
Ejemplo para 24 bpp: 

dx=*(bump+left) - *(bump+right); 
dy-*(bump+up) - *(bump+down); 

*(vid+(cvid+j)*3)=*(light+( ( c!íght+j+dx+dy*UGH 
TXSIZE)&262143)*3); 

*(v¡d+(<yid+j)*3+1 U*(!iqht+((cliqht+i+dx+dy*LI 
GHT_XSIZE)&262143)*3 + 1); 

*(vid+(cvid+¡) *3+2)=*(Hqht+(\(cl¡qht+j+dx+dy*U 
GHT_XSIZE)&262143)*3 + 2); 

Como se puede ver, el presente código es muy 
similar para cualquiera de los tres tipos de 
modo de vídeo con los que trabajamos. La 




Figura 3. Este es el resultado final. Es realmente 

SORPRENDENTE LA CALIDAD GRAFICA DEL EFECTO FINAL. 


única diferencia, básicamente, consiste en el 
empleo de los punteros adecuados. La 
inicialización correcta de estos punteros se 
realiza en las siguientes líneas: 

WORD *wvid=(WORD *)vid; 

WORD *wüght=(WORD *)iight; 

DWORD *dvid=(DWORD *)v¡d; 

DWORD *díight=(DWORD *)!ight; 

Tódo el código aparecerá junto al ejecutable 
dentro del CD-Rom que acompaña a la 
revista. Seguimos empleando nuestas rutinas 
habituales que trabajan con la API Direct X y 
que se compilan bajo Visual C++. Es 
aconsejable que aquellos lectores que quieran 
ver todas las posibilidades reales de este 
código juegue con los diversos valores que 
tiene y observe los distintos resultados que se 
pueden obtener con él. Desde luego, la 
calidad gráfica que se puede conseguir con el 
mismo es innegable. 

Con esto terminamos nuestra primera entrega 
acerca del Bump-Mapping centrado en las dos 
dimensiones. En los próximos artículos de esta 
serie veremos muchos más efectos que 
podemos realizar y su aplicación al Bump- 
Mapping 3D que es el objetivo final de esta 
serie de artículos. 

Recordamos que la dirección de correo del 
autor sigue abierta a todos vosotros para 
cualquier tipo de sugerencia que se os ocurra 
hacer tras leer estas páginas. Se responderá a 
todos los mensajes lo antes posible. A 


Fe de errores 

Hemos descubierto algunos «bugs» en las rutinas de 
Tga, que ya ofrecimos hace tiempo, Sobre todo había 
algunos fallos serios en la función que se encargaba 
de capturar las pantallas. Son problemas derivados 
del portado a C++ y sobre todo debidos a descuidos 
del autor de estas líneas, Este mes entregamos un 
nuevo código fuente <tga.cpp> revisado y con todos 
los fallos corregidos. Gracias a todos aquellos que 
nos habéis avisado de estos problemas. 
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DIV GOMES STUDIO 


Resolución de Apos de juegos 


Seguimos con la nueva etapa de DIV dentro 
de la revista Carne Over. Este mes 
continuamos hablando de la problemática 
de los distintos tipos de juegos. Veremos los 
juegos del tipo Shoot'em'up, conocidos en 
España comúnmente como matamarcianos. 


T odos hemos jugado alguna 
vez a algún Shoot'em'up. 

Pero este nombre proviene del 
idioma anglosajón. Su traducción 
podría ser algo así como 
«cárgatelos a disparos». En 
España, este tipo de juego es más 
conocido como matamarcianos. 

FUNDAMENTOS 

Los juegos de matamarcianos son 
de los más simples en su 
realización, aunque también se 
pueden complicar hasta límites 
insospechados. Es decir, si 
únicamente se quiere hacer un 
Shoot'em'up donde exista una 
nave protagonista que se dedique 
a eliminar hordas de enemigos, 
una detrás de otra, la 
programación de dicho juego 
puede ser muy simple, y más si los 
enemigos no son muy ínte/ígentes. 
Pero si se quiere un juego más 
trabajado, se pueden incorporar 
multitud de detalles y mejoras. 
Algo fundamental en este tipo de 
juegos son los disparos. Tanto los 
disparos de la nave protagonista 
como los de los enemigos, si 
estos dispararan, pueden 
funcionar de distintas formas. 
Aunque lo más normal es que la 
nave protagonista dispare hacia 
arriba o hacia un lado, o en 
general hada adelante, y los 
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enemigos tengan bastante buena 
puntería a! intentar acertar a la 
nave protagonista. Se pueden 
incorporar distintos tipos de 
disparo durante el juego, como 
misiles, disparo doble, mega- 
bombas, etc. Los distintos 
disparos pueden ser utilizables 
durante todo el juego, o 
únicamente ser accesibles 
mediante una serie de bonus, que 
son recolectadles. Pero de los 
bonus hablaremos más adelante. 

Algo fundamental 
en este tipo 
de juegos son 
los disparos 

Una vez con el protagonista, que 
es la nave dirigida por e! jugador, 
con los enemigos y los disparos, 
uno de los temas que el 
programador debe elegir es el 
modo de visión del videojuego. 
Normalmente las vistas más usadas 
son la aérea y la lateral. También 
puede que se quiera elegir entre si 
existe movimiento de pantalla o, 
como también se denomina, scroll. 
Si existe dicho movimiento, puede 
ser vertical, horizontal e incluso 
multidireccional. 

Otro de ¡os temas es si se 
dispondrá de decorado. Pero no 


solo hablamos de un decorado de 
fondo, sino que lo que se intenta 
comentar es si existiera un 
decorado con el que el jugador 
pudiera interactuar. Es decir, que 
se pueda chocar, o simplemente 
que le haga un efecto de pared. 
Además, como ya se comentó, 
existe la posibilidad, muy 
utilizada en estos juegos, de los 
bonus. Son una especie de 
objetos que el jugador puede 
recoger, y que le otorgan a la 
nave protagonista una serie de 
mejoras, como distintos tipos de 
disparos, inmunidad, o mayor 
capacidad de destrucción. 
También, en algunos juegos, 
existen una serie de enemigos, 
que son más difíciles de matar, y 
que normalmente están al final de 
la fase. Siempre y cuando el juego 
tenga distintas fases y niveles. 

PROBLEMATICA 

En este apartado vemos los 
distintos problemas, de forma 
más detallada, que nos podemos 
encontrar al programar un 
Shoot'em'up. El primero de ellos 
es el movimiento del 
protagonista, cuya forma de 
funcionar debe elegir él mismo. 
Este movimiento puede ser en 
una única dirección o 
multidireccional. También puede 
darse ei caso de que la nave 
protagonista se mueva según se 
pulse el teclado o girando. Es decir, 
en el primer caso, si se pulsa la 
teda de arriba, la nave se moverá 
hacia arriba; y en el segundo caso 
avanzará hada delante, y cuando 


se pulse las tedas de izquierda y 
derecha girará. 

Aparte de este movimiento de la 
nave, hay que tener en cuenta el 
movimiento del juego en sí. Es 
decir, si tendrá o no scroll o 
movimiento de pantalla, y hacia 
qué dirección se realizará tal 
movimiento. Puede darse el caso 
de que, dependiendo de la fase, el 
movimiento del juego en general 
vane, pero esto es elección del 
programador, como casi todo. 
Siguiendo con ios movimientos, 
seguiremos hablando esta vez 
de los enemigos. El tipo de 
movimiento se podría dividir en 
dos. Bien con trayectoria, bien 
inteligente, o sem¡-inteligente. 
Con el primero de ellos se 
puede diseñar un editor de 
trayectorias. El que 
denominamos inteligente es 
aquel que tiene una especie de 
seguimiento del protagonista o 
de cualquier otro elemento. 
También puede haber enemigos 
que no se muevan, pero estos 
ya lo veremos cuando hablemos 
del decorado. 

Una vez vistos estos elementos 
comentaremos los disparos. El 
primero de ellos será el disparo 
simple que tiene el jugador, 
aunque también puede existir el 
disparo múltiple. Incluso se 
podrían incluir misiles, bombas y 
megabombas. Además de estos 
disparos, por supuesto estarán ios 
de los enemigos. Estos 
normalmente irán destinados a la 
nave protagonista, es decir, 
apuntando a dicha nave. 











Figura 2. 


Otro tema problemático es si se 
quiere incluir un escenario, 
además del que haga las veces de 
fondo. Es decir, una serie de 
paredes que evitan que la nave 
pase por ese punto. Puede que 
dicho muro sea o no peligroso 
para el protagonista. Es decir, se 
puede elegir entre que el 
escenario quite o no energía a la 
nave protagonista. Además, se 
pueden integrar enemigos no 
móviles, es decir, que estén 
integrados dentro del escenario. 
Por lo tanto, si se tiene escenario se 
debe controlar el choque o colisión 
con el mismo. Y se deberían 
detectar, lógicamente, las 
colisiones con los enemigos. 

Incluso se puede dar el caso de que 
parte del escenario o enemigo sea 
peligroso para el protagonista, y 
por lo tanto le quite energía, y otra 
parte del mismo sea indiferente, es 
decir que el protagonista pueda 
pasar por encima. 

Cambiando de tema, pasemos a 
los bonus. Se pueden conseguir 
al pasar por ciertas partes del 
mapa de juego, o cuando se 
elimine a una serie de enemigos. 
Estos bonus, pueden dar distintos 
tipos de disparos, vidas, o incluso 
escudos. Y hablando de escudos, 
estos pueden tener multitud de 
formas, ya que pueden ser totales, 
parciales o incluso siendo estos los 
más complicados de programar, 
móviles, pudiendo por ejemplo 
dar vueltas alrededor de la nave. 


Por último comentar los cambios 
de fase, si el juego dispusiera de 
ellas. Y si se diera el caso, también 
los enemigos de fin de fase. Estos 
suelen ser de gran tamaño, y más 
difíciles de matar que el resto. 
Tanto este enemigo como la nave 
protagonista pueden tener un 
nivel de energía. Normalmente, 
cuando una nave es alcanzada 
automáticamente es destruida, 
aunque se podría ¡mplementar 
una barra de energía que les diera 
una longevidad mayor. 

Con esta enumeración quedan 
explicados todos los problemas 
que nos podemos encontrar al 
programar un juego de este 
tipo. A continuación, 
presentamos las soluciones DIV 
para estos problemas. 

RESOLUCION 

El primer problema que nos 
encontramos es mover la nave 
protagonista. Se puede optar por 
un movimiento direccional o 
relativo. Entendiendo como 
movimiento direccional aquel en 
el que cuando se pulsa la tecla 
derecha la nave se dirigirá a dicha 
dirección. En cuanto al 
movimiento llamado relativo lo 
podríamos denominar como 
aquel que se realiza del siguiente 
modo. Cuando se pulse las teclas 
de izquierda o derecha, el 
protagonista girará, y avanzará 
cuando se pulse la tecla de 
dirección arriba. 


Para poder mover con 
movimiento direccional, 
únicamente se deben alterar las 
coordenadas del proceso 
protagonista. Es decir, sus 
variables locales X e Y, 
incrementando o decrementan- 
do según convenga. Si se usa el 
otro método, usaremos la 
variable local angie para que el 
protagonista gire. Además, 
también se debe usar la función 
advanceQ para cuando queramos 
la nave avance. Con esto queda 
visto el movimiento de la nave, 
ya que no suelen utilizarse otros 
efectos, como la inercia o la 
gravedad. 

Existe la posibilidad, 
muy utilizada, de 
incluir bonus 

Lo siguiente a estudiar es el 
movimiento del juego en sí. Es 
decir, si tendrá pantalla fija o 
con movimiento. En el primer 
caso no hay ningún problema, 
ya que usando la función 
put_screen() pondremos un 
fondo de pantalla, que a la vez 
lo será de nuestro juego. Sí se 
opta por el saoll , o movimiento 
de pantalla, se dispone de la 
función start_saoll() f que 
cumple este cometido. Se puede 
optar por mover el saoll 
automáticamente, es decir, que 
siga al proceso protagonista. 

Pero también se puede hacer de 
modo manual, retocando los 
campos xü, yO, xl e yl de la 


estructura saoll. En cualquier 
caso, la forma de programar esto 
es sumamente sencilla. 

Seguimos hablando de 
movimientos, en este caso el de 
los enemigos. Por un lado, 
podemos hacer que el tipo de 
movimiento, sea del tipo 
trayectoria. Para facilitar la 
programación de estas 
trayectorias se puede construir un 
mapeador, que nos permita 
colocar los enemigos en su 
posición inicial, y luego indicar el 
movimiento que realizarán. Este 
tipo de movimiento puede ir 
mediante una fórmula, o 
simplemente mediante 
coordenadas relativas. Es decir, 
indicar los puntos por donde 
pasará el enemigo. 

También se puede optar por un 
tipo de movimiento más 
inteligente, A este tipo lo 
denominaremos de seguimiento. 
Consistirá en ir directamente a 
por la nave protagonista, 
cogiendo sus coordenadas y 
haciendo que los enemigos 
apunten a las mismas y avancen. 
Se puede poner alguna pared, 
aunque dificultará la 
programación del juego, facilitará 
la labor del jugador. Por último 
quedan los enemigos que no se 
mueven, o lo que es lo mismo, 
inmóviles. Aunque de este tema, 
se hablará más adelante. 

Ahora pasemos a hablar de los 
disparos. Todos ellos, 
normalmente, deben tomar las 
coordenadas del protagonista 


El mundo de los video juegos 

Se ha abierta una nueva etapa dentro de estos artículos, con les que os 
entretenemos cada mes. El denominador común de todos ellos es que tratan 
vid e ojuegos, comentando sus fundamentes, viendo su problemática y dando 
solución a los problemas. La liste completa de esta serie de artículos es la que 
viene a continuación, aunque siempre puede que haya cambios de última hora, ahí 
va dicha lista; 

* Arcada de plataformas. 

* ShootWup. 

< Puzzles y tetris. 

* Comecocos y juegos especíales, 

* Juegos de cartas y de mesa. 

* Aventuras conversación ates. 

* Rol / RPG. 

* Juegos de lucha. 

4 Simuladores deportivos. 

* Simuladores de vuelo, 

* Simuladores en general. 

* Estrategia. 

* Juegos tipo DOQM 











como posición inicial. Luego 
moverse por la pantalla según el 
movimiento estipulado, para al fin 
comprobar si ha desaparecido de 
pantalla, etc. Dentro de los 
disparos podemos hablar primero 
del más simple, el único, el más 
típico. Se puede optar por un 
disparo múltiple, en este caso se 
debe programar el movimiento 
de cada bala y luego crearla. Para 
crear distintas balas, con un sólo 
proceso y variar su 
comportamiento, podemos usar 
el paso de parámetros. 

Otro tema, hablando de disparos, 
es el de los misiles. Es este caso se 
debe optar por el tipo de misil a 
usar. Dentro de los tipos posibles 
nos encontramos primeramente 
con aquel que se comporta como 
un disparo normal, pero con 
mucha más potencia destructiva. 
Llevado esto hasta los límites, nos 
encontraríamos con los disparos 
de megabombas, es decir, 
aquellos que destruyen gran 
cantidad de enemigos a la vez. 
Aunque se podría convertir estas 
megabombas en misiles. 

Por último, nos encontramos con 
los misiles más difíciles de 
programar, los conocidos como 
de seguimiento o misiles 
inteligentes. En estos casos se 
debe tener en cuenta que hay 
que seleccionar un enemigo para 
que el misil lo siga. Además, hay 
que tener cuenta que no se 
pueden enviar dos misiles a un 
mismo enemigo, por lo que se 
deberá tener control sobre los 
misiles enviados. 

Además tenemos los disparos de 
los enemigos, que se pueden 
comportar de forma parecida a los 
disparos descritos para la nave 
protagonista. Aunque lo que 
normalmente se hace es que los 
disparos enemigos se dirijan hada 
la nave protagonista. Es decir, que 
a la hora de ser lanzados tomen 
las coordenadas actuales del 
protagonista y se dirijan hacia 
dicho punto. La programación de 
este tipo de disparo no tiene 
mucha complicación. Pero si se 
quiere dificultar realmente la labor 
del jugador, los disparos que son 
más difíciles de evitar son aquellos 
que hacen un seguimiento 
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Grandes nombres en el Shoorem up 

Ha habido grandes nombres dentro da los Shoot'em up desda tiemi 
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continuo del protagonista. Es 
decir, siguen a éste todo el rato, 
aunque si no se quiere hacer las 
cosas tan difíciles, en vez de 
asignar el ángulo donde se va a 
dirigir directamente se puede usar 
la función nearjmgled lo que 
hará que se dirija poco a poco, e 
incluso que se ponga a dar vueltas 
alrededor de la nave. 

Ahora pasemos al tema del 
escenario, si es que se va a diseñar 
nuestro juego con esta capacidad. 
Una vez diseñado el escenario, se 
puede hacer que éste sea 
peligroso, o simplemente sea una 
pared sin ningún peligro. Tanto 
en un caso como en el otro, se 
deben usar mapas de durezas 
para indicar dónde hay pared y 
dónde no. Como se dijo, un 
mapa de durezas es un gráfico 
que tiene pintado de un color los 
huecos, y de otro las paredes. 
Unicamente se debe comprobar 
en qué posición se encuentra el 
protagonista dentro del mapa de 
durezas para saber si está o no 
encima de una pared. Otro 
método menos fiable es crear el 
escenario como un proceso y usar 
la función coltision. 

Y también hablando de escenarios, 
nos encontramos con los 
enemigos de escenario. Son 
estáticos, no se moverán de su 
posición, su programación es 
sencilla, tanto si usamos o no el 
scroli En los dos casos, la única 
diferencia entre estos enemigos y 
los otros es que estos no varían sus 
coordenadas durante la ejecución. 
Cambiando de tema, seguiremos 
hablando de las colisiones y los 
choques. Como anteriormente se 
dijo, existen dos maneras de 
detectar choques con el 
escenario, bien con los mapas de 
durezas, bien usando la función 
collhionQ. Para los enemigos, 
disparos y demás objetos del 
juego, la única forma será usar 
esta fundón, que detecta el 
choque entre dos procesos. 

Ya por último queda hablar de los 
bonus. Se consiguen, por ejemplo, 
at eliminar una horda entera de 
enemigos. Suele dar más opciones 
de destrucción, como 
multidisparos, o vidas, o también 
algún tipo de escudo. Y hablando 


de escudos, para programar estos 
lo que se debe tener, aparte del 
gráfico que lo simule, es una 
variable de estado dentro del 
proceso protagonista que indique 
si la nave es vulnerable o no. Otro 
tema a tener en cuenta es que si 
las naves poseerá energía o 
simplemente podrá ser destruida 
en el primer disparo. Para manejar 
la energía se puede crear una 
variable local del mismo nombre. 

Y para finalizar quedan los 
enemigos fin de fase y los 
cambios de fase. En el último 
caso, únicamente es necesario dos 
variables para controlar todo. Una 
que indique el número de fase y 
otra que indique si se ha acabado 
o no. Comprobando esta última 
variable se sabrá si el jugador ha 
acabado o no. He incluso si lo 
programamos correctamente, 
mediante un valor determinado, 
podemos conocer de qué modo 
ha acabado. En cuanto a ios 


enemigos de fin de fase, son 
enemigos especiales que 
aparecen ai final de cada nivel. 
Normalmente tienen más 
energía que los otros y se les 
debe disparar más veces. Sobre 
su comportamiento, se pueden 
usar las técnicas descritas para 
los demás enemigos, y usarlas 
con este tipo teniendo siempre 
en cuenta las diferencias entre 
los mismos. 


temiendo 

Bueno, ya nos despedimos por 
hoy, el mes que viene 
comentaremos otro estila en 
cuanto a videojuegos. Si teñáis 
alguna duda, os podáis poner er 
contacto con el autor en el E-rru 
tizoilüümbps.ss, donde dentro 
de lo posible intentaremos 
solucionarla. Ei mes que viene n 
vemos por estas páginas, que o 
Divirtáis programando. 












CODIGO COMPLETO 


mr: Carlos Glez. Morcillo 

cgonmor@jet.es 


flnarhanoid. el 
machacaladrlllos sin reglas 


Como la mejor forma de saber hacer juegos es 
ponerse a practicar, en esta sección todos los meses 
incluiremos el código fuente de un juego completo 
junto con un informe técnico de cómo se hizo e 
información útil para los desarrolladores. 


E ste mes abrimos una nueva sección en 
Carne Developer, donde incluiremos 
códigos fuente completos de varios juegos. 

Ésta es una de las mejores formas de aprender 
secretos de diversos programadores; además, 
viendo el código fuente completo podremos 
practicar y modificarlo como nos venga en 
gana. El videojuego de este mes es similar al 
legendario Arkanoid; consiste en dar con una 
pala a una pelota para romper los ladrillos de la 
parte superior de la pantalla. Está desarrollado 
en Turbo Pascal 7 sin utilización de BGI, y el 
modo de vídeo utilizado es el 13H (320x200 a 
256 colores). Para las rutinas que tienen que 
ser muy rápidas (como volcado de pantallas 
virtuales a pantalla real) se ha utilizado 
Ensamblador, pero únicamente en las partes 
en que era estrictamente necesario. 


Al estar programado en Turbo Pascal, la 
traducción a otros lenguajes como C o DIV es 
bastante sencilla, y de esta forma 
ampliaremos nuestros horizontes. Como en 
una página es imposible explicar el desarrollo 
de un videojuego completo, hemos incluido 
en el directorio de fuentes {/informé} un 
documento de 1 7 páginas (formato Word 97) 
donde se explica detalladamente cómo se fue 
desarrollando el videojuego desde el 
principio, pegas que se plantearon, 
soluciones, etc. Algunos de los temas tratados 
en el informe son: 

* Descripción y utilización del modo de 
vídeo 1 3H. 

* La paleta gráfica, irucialización y efectos. 

* El problema del retrazado y su solución. 

* El ratón, implementación. 


* Estructura general del juego. 

* Colisiones, el algoritmo de Bresenh^m. 

Cualquier programador, por muy novato que 

sea, podrá entender fácilmente el código 
fuente de este juego y profundizar en sus 
conocimientos. El juego puede mejorarse en 
varios aspectos, que dejamos como ejercicios 
propuestos a nuestros lectores: 

* Incorporación de efectos de sonido. 

* Música ambiental de fondo (por ejemplo, 
incluirla con Midas). 

* Mejorar el algoritmo de colisiones. 

* Incluir premios cuando se rompan algunos 
ladrillos (que la pala aumente o disminuya 
su tamaño, vidas extras, aumentar o 
disminuir la velocidad de la bola, en fin, 
como en el Arkanoid original). 

* Mejorar el aspecto gráfico dei juego, etc. 

Todo lo que se nos ocurra. Dejamos el juego 

abierto a vuestras propias ideas. Además, 
podéis contactar con el autor del juego para 
presentarle vuestras dudas, quejas o lo que 
queráis escribiendo a cgonmor§jeies 
Esperamos que disfrutéis con esta nueva 
sección y estad al loro, que pronto vendrán 
nuevas sorpresas, y nuevos juegos a los que de 
este mismo modo destriparemos. 


DIGITAL. DREAMS MULTIMEDIA 


PROGRAMADORES 

Ref. Programador 

» Dominio de programación en LINGO 
y/o VISUAL BASIC y C++. 
f Amplios conocimientos de 
programación orientada a objetos y/o 
programación en Internet, 

' Se valorará experiencia en el 
desarrollo de proyectos multimedia. 


empresa de creación y edición de software 

SELECCIONA 

DISEÑADOR GRÁFICO 

Ref. Diseñador gráfico 

• Dominio de los programas Photoshop, 
3DStudio MAX y Paint Shop Pro. 

• Estudios o conocimientos de diseño gráfico 
en entorno multimedia, 

• Se valorará experiencia en el desarrollo de 
diseños multimedia. 


REALIZADOR DE VIDEO MULTIMEDIA 

Reí. Realizador vídeo 

* Dominio de loa programas GDStudic 
MAX, Phstoshop, Premie re y After 
Effects. 

* Conocimientos de la narrativa 
documental y cinematográfica. 

* Interés por fa edición de vídeo 
multimedia. 


OFRECEMOS 

* Contrato laboral, retribución a 
convenir según la valía del 
candidato e incorporación 
inmediata a equipo de trabajo. 


Envía tu curriculum vitae, indicando la referencia en el sobre, a la siguiente dirección: 


Digital Dreams Multimedia, 

G/ Alfonso Gómez, 42, Nave 1-1-2 
28037 Madrid 


Digital 

jj teams 


□ por e-mail a ddmuftimedia@ddmultimedia.com 
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DIRECTX 


El uirapper 


Este mes vamos a hacer un pequeño descanso y repasar lo 
que hemos visto hasta ahora. Nuestro wrapper ya es bastante 
útil, así que vamos a hacer una pequeña referencia para su 
buen uso. También echaremos un vistazo a los recursos que 
existen en Internet para el desarrollo en DirectX. 


A ctualmente, nuestro wrapper está dividido 
en tres módulos: la dase GDDirectDraw, 
la clase GDDDSurface y la depuración. 

A partir de ahora, nuestro trabajo se centrará 
en completar ía serie con la implementación 
de los clippen, el manejo de paletas, los 
dispositivos de entrada y los de sonido, 

DEPURACION 

Una buena parte del trabajo de desarrollo de 
cualquier programa se invierte en la depuración. 
Para nuestro wrapper hemos creado una macro 
que nos permite visualizar mensajes en la 
ventana de depuración de Visual C. 

PRINTD(cadena) 

Cuando invocamos a PRINTD, éste manda la 
cadena que le hayamos pasado, junto con 
información sobre el fichero y la línea de 
código fuente desde el que se le llamó a la 
ventana de depuración. Aquí vemos un 
ejemplo de la salida generada por PRINTD: 

***> GDDDSurface::setColorKey(DWORD 
color) -> D:\Curso 

DirectX \ Ejemplo5\Entrega5 \ G DDDSuríace. cpp (360) 
Figura 1 .Pagina principal de DirectX en Microsoft. 


La salida contiene: primero, la cadena «***>», 
que nos sirve para diferenciar salidas de 
depuración nuestras de las de DirectX y así 
identificadas mejor; después, la cadena pasada 
a PRINTD; tras la cadena «->» encontramos el 
fichero desde el que se llamó a la macro; y 
finalmente, entre paréntesis, el número de 
línea. Podéis echar un vistazo a la línea 360 del 
fichero GDDDSurface.cpp para ver cómo se 
invocó a la macro. 

Es recomendable usar PRINTD para saber por 
dónde está discurriendo nuestro programa. Por 
eso, en el wrapper usamos PRINTD antes de 
constructores, destructores y funciones 
complejas. También es recomendable utilizarlo 
en caso de error leve en el programa. 

El buen empleo de estas sencillas técnicas nos 
evitará muchas horas de depuración, ya que en 


muchos casos evitaremos tener que ir trazando 
línea por línea, casi a ciegas. Tenemos también 
que tener en cuenta que no podemos Ir 
ejecutando línea a línea una aplicación 
DirectDraw en pantalla completa, con lo que 
las dudas que pudierais tener respecto a esta 
técnica hayan sido ya despejadas. 

CLASE GDDDIRECTDRAW 

Esta clase encapsula un objeto JDirectDraw2, 
facilitando tareas como el establecer modos de 
vídeo, cooperatividad y füpping. 

El wrapper posee aún ciertas limitaciones. No 
es capaz todavía de manejar modos gráficos 
en ventana y los modos creados en pantalla 
completa deben tener al menos un huffer\ 

Estos inconvenientes se irán resolviendo 
durante el curso. 

Vamos a ver los distintos métodos: 

• GDDirectDrawQ: Es el constructor por 
defecto. Simplemente crea el objeto 
IDirectDraw2 para su posterior utilización. 

• CDDirectDraw (HWND hwnd): Igual que el 
constructor. Además, se inicia con un 
handle a la ventana de nuestra aplicación. 
Este handle es necesario para que el 
wrapper sea funcional. 

• GDDirectDraw {HWND hwnd , int width, 
int height, int bpp - -7, booí futíScreen = 
TRt/E): Este constructor inicia el wrapper y 
establece un modo de vídeo. Ver el 
método setMode para la lista de 
parámetros. 

• -GDDirectDrawQ: Destructor del wrapper. 
Se encarga de eliminar todos los objetos 
creados, 

• void setHWND(HWND hwnd): Esta función 
sirve para indicar el handle de ventana a 
usar. Suele usarse tras crear el objeto 
mediante el constructor por defecto, ya 
que es necesario el handle para que el 
wrapper funcione. 

• HWND getHWND(void): Este método sirve 
para obtener el handle asignado a este 
objeto. 
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Ficheros del Wrapper 

• Clase GDDirectDraw 

GÍJOt rectora iv,/i 
GDDírectriraiv.cpp 

• Clase GDDDSurface 

GOGiJSurface.fi 
GDDDSurface. cpp 
■ Herramientas de depuración 
GDDebug.h 
GDDebug. cpp 

• Métodos auxiliares 

DdutiisB.h 

DdjrtfJtJiTs^.crpp 


Listas de correo DirecIX 

Angelie-eoders 

Http://mtm, angeiic-coders, com/ 

BirectXBev@ange íic-coders , com 

Ésta es una magnifica lista de correo sobre DirectX» 
en la que participan activamente varios miembros del 
propio equipo de desarrolla de las librerías, Es 
bastante visitada, por tanto prepárate a recibir unas 
50 mensajes diarios SÍ na activas el modo digest, el 
cual te permite recibir un carrea diaria conteniendo 
todos los mensajes enviados a la lista ese día. 



Figura 2 . En plena sesión de depuración. 


• HRESUÍT getError(void): Este método nos 
va a resultar muy familiar. Devuelve el 
último error producido dentro del wropper. 

• booi hFull$creen(void): Devuelve True si el 
modo de vídeo es en pantalla completa, y 
False si es en ventana. 

• HAESUIT getDC(HDC hdc): Este método 
permite obtener el DC del bad buffer, para 
poder dibujar en él medíante el GDL 

• relea seDC (HDC hdc): Libera un 
DC previamente obtenido con getDC 

• HfifSUU fíÍp(void): Efectúa el flipping entre 
el back buffer y el froní buffer. El método 
espera a que pueda realizarse el flip, 
restaurando surfaces si éstas se pierden. 

• LPDIRECTDRAW2 get(voíd): Sirve para 
obtener el objeto IDirectDrawl que 
encapsula el wropper, para así poder efectuar 
tareas no imptementadas en esta clase, 

• GDDDSurface* getBack{void): Esta 
función devuelve el bacfc buffer (nótese que 
devuelve un objeto GDDDSurface). 


ramación 


* GDDDSurface 4 getPrim(void): Este 
método devuelve el front buffer. 

• HRESULT setMode(int width, int foeight, 
¡nt bpp = -1, int backbuffers = 1, bool 
fulIScreen = TRUE): Esta función establece 
un modo de vídeo, teniendo en cuenta las 
limitaciones del estado de implementación 
actual del wropper . Veamos para qué sirve 
cada parámetro: 

* wúfth: Indica el ancho de modo de 
vídeo (en pixels). 

• height Indica el alto del modo de 
vídeo. 

* bpp: indica la profundidad de color del 
modo deseado(expresado en bits por 
píxel). Si solicitamos un modo en 
ventana, este parámetro será ignorado. 

• Back bufíers: El número de back buffers 
que deseamos que tenga nuestro modo 
de vídeo. En caso de indicar un modo 
en ventana, estos buffers serán 
emulados por el wropper : 



• fulIScreen: Indica si queremos el modo 
de vídeo en pantalla completa o en 
ventana, 

CLASE GDDDSURFACE 

Esta clase encapsula un objeto 
ID¡rectDrawSurface3, y permite liberarnos de 
muchas de las tareas repetitivas que conllevan 
la gestión de este tipo de objetos, 
implementando las fundones elementales en el 
proceso de dibujo. 

A este wropper le falta aún la creación de más 
tipos de constructores, así como un constructor 
de copia. Aun así, las funciones creote() suplen 
la carencia de dichos constructores, por lo cual 
son perfectamente funcionales. 

Todas las fundones create(...) borran el 
contenido del wrapper y lo reinician al ser 
llamadas. 

• GDDDSurfoce(): Es el constructor por 
defecto. No hace nada salvo inicializar el 
wrapper. 

• -GDDDSurfaceQ: El destructor del wrapper. 
Libera todos los objetos necesarios. 

• HREJUÜT creofeíCDD/rectDrow* owner, 
LPDtRECTDRAWSURFACE IpDDSurf): Esta 
fundón inicia el wrapper a partir de un 
objeto IDirectDrawSurface. 

• owner. Puntero al objeto GDDirectDraw 
al que pertenece la surfoce. 

• ipDDSurt Puntero al objeto surfoce a 
encapsular. Dicho objeto queda 
inservible a partir de este momento y 
solamente puede ser usado desde el 
wrapper. 

• HRESULT create(GDDirectDraw* owner, int 
numBackBufíers): Esta función crea una 
surfoce con uno o varios back buffers. 

• owner. Igual que en el método anterior. 

• numBackBufíers: Número de back 
buffers que deseamos en el wrapper. 

• HRESULT creóte (GDDirectDraw* owner, 
constchor* fichero): Esta función inicia el 
wrapper cargando un fichero BMP en la 


IRC-Hispano 

SI tenéis alguna duda sobre DirectX y preferís 
comentarla junta a atrae personas en vivo, probad 
en ios siguientes canales: 

* típrogramadanstratos: Este canal está 
frecuentado par desarrolla da res de videoiuegos, 
así que no seré difícil encontrar algún 
programador de DirectX que os resuelva tas 
dudas, 

* #programación, ^informáticos; Estos canales 
son de carácter más general, pero os será fácil 
encontrar a alguien que domine DirectX, 

* #demos: Aunque la demoseene no esté aún muy 
metida en desarrollar aplicaciones DirectX, aquí 
encontrareis verdaderos maestras de la 
programación gráfica. 









































surface. La surface creada tendrá las 
dimensiones del BMP, y en caso de 
pérdida, al restaurarla se volverá a cargar 
dicho fichero, 

• owner. Igual que en métodos 
anteriores. 

• fichero: El nombre del fichero BMP a 
cargar, 

• HRESULT createBackBuffer(GDDDSurface 
*prímary): Esta función crea un wrapper 
que referencia el back buffer de la surface 
dada. Al liberar este wrapper, la ¡urface 
encapsulada no se libera. 

• primary: Surface a partir de cuyo back 
buffer se creará el wrapper. 

• LPDIRECTDRAWSURFACE3 get(): Esta 
función permite obtener el objeto 
IDirectDrawSurface3 encapsulado, para 
acceder a él directamente. 

• GDDDSurface* getBackBufferQ: Esta 
función devuelve (si existe) un wrapper 
conteniendo el back buffer de este objeto. 

• HRESULT blitOpaquefint x, int y): Esta 
función dibuja (blit) de modo opaco 
nuestra surface en el back buffer principal. 

• x: Coordenada horizontal de la surface 
de destino donde se dibujará. 

• y- Coordenada vertical de ia surface de 
destino donde se dibujará. 

• HRESULT blitTrans(íntx, int y): Esta 
función dibuja de modo transparente (con 
el color key) nuestra surface en el back 
buffer principal. 

• k Coordenada horizontal de la surface 
de destino donde se dibujará. 

• y- Coordenada vertical de la surface de 
destino donde se dibujará. 


Webs ile DifeclK 

* Página oficial de DirectX en Microsoft 

Httpi//www. microsoft. com/directx/defautt, asp 

En esta web encontraréis las últimas 
informa cienes oficiales sobre DirectX, asi como 
dawnloads del SDK, run-times y utilidades para 
las librerías, aparte de mache información de 
interés. 

•Enlaces de desarrollo en StRAtOS 

Http: //mm straio^ad. com/stra tos/enlaces htm 

En la página de este asociación podréis 
encontrar un listado de enlaces a diferentes 
sitios sobre DirectX, así como a otras páginas 
relacionadas con el desarrollo de uideojuegos. 

• Fbating point 

Http://www. benS . ucía. edu/~pemadi/game¡ink/ 
gamelink.html 


Cabecero de la clase GDDirecfflraui 

Class GDDirectDraw 

GDDDSurface* getPrim(void) 

{ 

const {retum jurfPrim;) 

public: //- 


-» public «— 

HRESULT setMode(mt width; int 


height, int bpp = -1, int backbuffers = 1, bool 

GDDirectDrawQ; 

fuilScreen = TRUE); 

GDDirectDraw(HWND hwnd); 


GDDirectDraw(HWND hwnd, int 

protected: //— -— 

width, int height, int bpp = - J, bool fuilScreen = 

» protected «— 

TRUE); 

prívate: // -- 

~GDDirectDrawQ 1; 

-» prívate «— 

vo id setHWND(HWND hwnd) { 

HRESULT createDirectDrawQ; 

hwnd = hwnd;}; 

HRESULT JnitQ; 

HWND getHWNDfvoid) const { 

HRESULT _createSurfaces(int 

return _hwnd;} 

backbuffers); 

HRESULT getErrorfvoid) const { 

boolvalid; // 

return _error;) 

Indica si el objeto se ha iniciado 

bool isFullScreen(void) const { 

HWND Jwnd; 

return JsFulIScreen;} 

bool isFulIScreen; 


HRESULT error; // 

HRESULT getDC(HDC* hdc); 

Ultimo error declarado 

HRESULT reteaseDC(HDC hdc); 

LPDIRECTDRAW2 JpDD; 

HRESULT flip(void); 

GDDDSurface* 


jurfPrim; 

LPDIRECTDRAW2 get(void) const { 

GDDDSurface* 

return JpDD;} 

_surfBack; 

GDDDSurface* getBack(void) 


consí {return jurfBack;) 

}; 

Figura 3. Otro programa de ejemplo para nuestro curso. 



Una inmejorable página de enlaces a recursos de 
programación de uideojuegos, entre ellos DirectX, 


P f o g f a m a c i B n 
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Figura 4. 


Cabecera de la clase GDSurface class GDDD Surface 


í 

public: //- 

-» public « 

GDDDSurfaceQ; 

~G DDDSurfaceQ; 

HRESULT create(GDDirectDraw* 
owner, LPDIRECTDRAWSURTACL ipDDSurf); 

HRESULT create(GDDirectDraw* 
owner, int numBackBuffers); 

HRESULT create(GDD¡rectDraw* 
owner, const char* fichero); 

HRESULT 

createBackBuffer( G DDDSurface *primary); 

LPDIRECTDRAWSURFACE3 get() 
const {return _surf; j 

G DDDSurface* getBackBufferQ; 

HRESULT blitOpaque(int x, int y); 
HRESULT blitTransfint x, int y); 
HRESULT blitRectTrons(¡nt x, int y, 
intx2, inty2); 

HRESULT 

setRGBColorKeyfCOLORREF color); 

HRESULT setColorKey(DWORD 

color); 

HRESULT getDC(HDC*hdc); 
HRESULT releaseDC(HDC hdc); 


HRESULT getError(void) const { 
return _error;} 

protected: //-—. .. 

» protected «— 

prívate: / / - . j 

-» prívate «— 

reloadQ; 

// Recarga la surface con su fichero 

HRESULT createfromEileQ; // 
Crea una surface desde un fichero 

HRESULT 

_upgradeToDDSurface3(LPDIRECTDRAWSURFAC 

ElpDDS); 

vo id _release(void); 

void _init(void); 


GDDirectDraw* _owner; 

boo!_vaiid; // 

Indica si el objeto se ha iniciado 

HRESULT _error; // 

Ultimo error declarado 

char* Jichero; // 

Nombre del fichero cargado (si hay que 

¡! restaurar) 

bool _esCopia; i1 


Indica sí hay que borrar el objeto 

LPDIRECTDRA WSURFACE3 jurf; 

}; 


• HRESULT blitRectTrans(int x, int y, intx2, 
int y2); Esta función dibuja de modo 
transparente nuestra surface en el back 
bu/fer principal, ajustándose a las 
dimensiones que le pasemos. Sirve por 
ejemplo para hacer zoom. 

• x, y. Esquina superior izquierda del 
rectángulo donde se dibujará ia surface. 

• x2, y2: Esquina inferior derecha del 
rectángulo donde se dibujará la surface. 

• HRESULT setRGBColorKey(COLORREF 
color): Esta función establece el color key 
mediante la función DDSetColorKey2 de 
ddutil2.cpp. 

• eo/or Color RGB que servirá de color 
transparente. Esta función efectúa 
transformación de color dependiendo 
del modo de vídeo utilizado. 

• HRESULT setColorKeyfDWORD color): Este 
método establece el valor del coior 
transparente para la surface. 

• color. Valor del color transparente. Esta 
función no efectúa ninguna 
transformación, con lo cual deberemos 
ajustar el valor al formato de píxel 
actual, o bien usarlo para modos de 
paleta. 

• HRESULT getDC(HDC* hdc): Este método 
permite obtener el DC de la surface, para 
poder dibujar en ella mediante el GDI. 

• HRESULT releaseDCfHDC hdc): Libera un 
DC previamente obtenido con getDC. 

• HRESULTgetErrorfvoid): Este método 
devuelve el último error producido en el 
wrapper. 

RECOPILANDO MAS INFORMACION 

La mejor fuente de información sobre DirectX 
es, sin duda, internet. Hemos hecho un hueco 
en este artículo para daros algunas pistas sobre 
la localización de estos valiosos bienes. 

Entre las distintas opciones existentes, hemos 
compilado una pequeña lista de recursos en la 
que caben páginas web, listas de correo, grupos 
de noticias e incluso canales de IRC. No os 
perdáis ninguna de estas referencias si queréis 
saber todo acerca de la tecnología DirectX. 

Para dudas, sugerencias o cualquier tipo de 
críticas os facilito mi dirección electrónica. 

¡ose Antonio Guerra Pablos 
balder@mindlessxom 


Grupos de News sobre DirectX 

Grupo oficial DirectX de Microsoft 
Servidor: mstfeivs,roímíSGft.com 
Grupo: micros □ ft, pub!ic M rc32.programmer.directa 
Este foro es una buena elección para estar al día en 
DirectX. Es bastante frecuentado] asi que preparad 
vuestros módems para recibir todos los mensajes. 
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Diseño y optimización de 
páginas uieb 


Si la cara es el espejo del alma, entonces 
la página web es el espejo de nuestro 
grupo de desarrollo. La velocidad a la que 
baje y su diseño serán decisivos a la hora 
de que los usuarios se queden a «bucear» 
en nuestra información. 


E ste artículo no pretende dar 
una iniciación al lenguaje HTML 
(para eso ya aprendimos con el 
artículo de Leticia Krahe publicado 
en Game Developer número 3), 
sino más bien consejos y ejemplos 
prácticos para mejorar la página 
web de nuestro grupo de 
desarrollo. En muchos grupos se 
plantea el problema de quién debe 
ocuparse del mantenimiento y 
elaboración de la página web. Si 
bien la mejor opción es que haya 
una persona dedicada 
exclusivamente a esta labor, esto 
nos puede suponer demasiado 
gasto y en la mayoría de los casos 
se hace cargo una persona que 
tiene otras funciones en el grupo. 
¿V quién debe ser? ¿Un 
programador, un grafista, un 
músico? Normalmente se suele 
encomendar al programador 
adentrarse en esos parajes, pero no 
es la mejor elección. Una página 
sobre todo tiene que entrar por los 
ojos (lo cual no significa que tiene 
que recargarse de imágenes), y el 
más adecuado para dar vistosidad 
a una web es un grafista. Esto no 
quiere decir que el resto de 
miembros del grupo no colaboren 
con el desarrollo de la web. De 

Figura 1. 


hecho, el programador podría 
hacer alguna aplicación en java o 
CGI por ejemplo. 

Los modernos editores de páginas 
web, con la filosofía WYSIWYG 
(What You See Is What You Cet, lo 
que ves es lo que obtienes) 
facilitan en gran medida la 
creación de documentos HTML 
sin tener casi ni idea de la enorme 
variedad de etiquetas que hay en 
este protocolo. Para los ejemplos, 
usaremos el editor que viene 
incorporado en Netscape 
Communicator versión 4.02, 

INICIOS 

Antes de ponernos a escribir en el 
editor como locos, deberemos 
pensar sobre qué vamos a incluir 
en nuestra página y qué diseño va 
a tener. Sena muy recomendable 
elaborar un guión entre todos los 
miembros del grupo y discutir qué 
información se va a incluir (texto y 
programas para bajarse), cómo se 
va a diseñar la página, etc. Es muy 
molesto visitar una web y no 
encontrar la información 
distribuida de alguna forma 
coherente. Una vez decidido todo 
esto, debemos tener en cuenta 
algunas recomendaciones: 


• La web debe actualizarse cada 
cierto tiempo. Para mantener 
la atención de nuestros 
visitantes, deberemos 
aportarles datos nuevos. Una 
buena costumbre es incluir 
una página de novedades, en 
donde detallaremos por 
orden cronológico las mejoras 
y actualizaciones que ha 
sufrido la web. Otra opción 
muy interesante es la 
elaboración de un formulario 
para contactar con los 
usuarios de nuestra página y 
conocer sus gustos y 
opiniones. 

• El contenido gráfico tiene una 
gran importancia. La principal 
diferencia entre una web 
profesional y una de 
aficionado es la incorporación 
o no de gráficos propios. Pero 
cuidado, el abuso en la 
utilización de gráficos no es 
muy recomendable, ya que la 
carga de imágenes aumenta 
el tiempo de "bajada" de una 
página. El tamaño máximo de 
una página (entre texto e 
imágenes) no deberá superar 


los 60 Kbytes (siendo esta 
cifra de por sí elevada). Esto 
se debe a que muchos 
usuarios de Internet poseen 
una conexión lenta y un 
tiempo de espera superior a 
15 ó 20 segundos, lo que 
puede incitarles a abandonar 
la visita a nuestra página. Así 
pues, es muy importante 
optimizar al máximo nuestras 
imágenes para reducir el 
tiempo de carga. Si queremos 
incluir imágenes grandes con 
una resolución muy buena, es 
aconsejable utilizar 
Thumbnaih (o catálogos en 
pequeño), y ofrecer las 
mismas imágenes en 
pequeño para orientar al 
visitante sobre qué va a 
obtener si desea cargar la 
imagen definitiva. 

• Debemos variar el tamaño y el 
color de la letra para ayudar al 
navegante en la búsqueda de 
la información que necesite. 

La forma de leer una web es 
distinta a la lectura de un 
documento impreso. La forma 
en la que se desplaza una web 
(en vertical), añadido a! 
condicionante de que la 
factura telefónica va 
aumentando, contribuye a 
que se lea a saltos y 
prácticamente sólo los 
titulares. De esta forma todas 
las páginas deben tener algo 
de valor, y no se debe incluir 
texto de relleno. 

• Tenemos que pensar que la 
mayoría de los navegantes no 
tienen ese último Plug-ln que 
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tú has conseguido, y muchos de ellos 
conexiones lentas. Usar texto alternativo 
en las imágenes es una buena práctica, y 
respecto al tema de los Plug-lns, lo mejor 
es que aprendamos a usarlos y les demos 
tiempo a nuestros navegantes a 
conseguirlos. Si nos decidimos a utilizarlo, 
incluyamos siempre un enlace a una 
página donde conseguirlo. 

• No hay nada más frustrante que seguir un 
enlace a una página "en construcción" es 
preferible que no funcione el enlace hasta 
que la página no esté lista, más todavía si 
tienes que cargar el típico gráfico del 
obrero trabajando con la pala. 

• Evitar construir páginas muy largas, 
además de ser incómodas para el visitante, 
las páginas cortas facilitan las tareas de 
mantenimiento y actualización. 

PRACTICANDO UN POCO 

Como ejemplo de este artículo haremos un 
sencillo formulario para nuestra página web. 

Sin duda alguna no es la mejor forma de 
elaborar un formulario, pero es la más sencilla 
y el resultado es bastante efectivo. Como 
hemos indicado antes, las imágenes deberán 
ocupar el menor espacio posible, para que 
bajen rápido. Deberemos elegir entre los dos 
formatos que soportan la inmensa mayoría de 
bmwsers: el GIF y el jPG. 

GIFV5.JPG 

El formato GIF tiene un sistema de compresión 
LZW bastante sencillo, que no degrada la 
imagen origina!, pero tampoco permite 
comprimir mucho ésta. Tendremos la 
limitación de trabajar con 256 colores, pero 
podremos realizar animaciones y fijar un color 
de transparencia. Por el contrario, el formato 
jPG utiliza un sistema de compresión más 
sofisticado, nos permite utilizar 24 bits de color 
y las compresiones son mucho mejores que en 
GIF. Como defectos del JPG podemos indicar 
que la imagen va perdiendo calidad según se 
aumenta la compresión, y además no 
podemos fijar colores transparentes ni hacer 
animaciones. 

Llegados a este punto, nos preguntamos 
¿cuándo utilizar cada formato? Pues 
utilizaremos GIF siempre y cuando las 
imágenes no sean excesivamente grandes y el 
paso a 256 colores (o menos) se pueda hacer 
sin perder calidad. Siempre que utilicemos una 
imagen de fondo de página, tendremos que 
usar transparencias, por lo que el formato GIF 
es el más adecuado. Para imágenes grandes, 
con muchos colores y gran definición, 
utilizaremos jPG, ya que su compresión es 
notablemente superior. 


Figura 2. 

ALGUNOS CONSEJOS PARA 
OPTIMIZAR IMAGENES 

Para imágenes GIF, deberemos ajustar el 
número de colores al mínimo, ya que influye en 
el tamaño final de la imagen. También 
podemos cambiar la escala de la imagen inicial 
por otra más pequeña (tamaño en pixels) para 
ahorrar bytes, y en el editor agrandar la 
imagen al tamaño que deseemos. De esta 
forma perderemos algo de definición, pero 
ganaremos en tiempo de bajada de la página. 
En GIF animados no deberemos realizar esta 
operación de cambio de escala, ya que algunos 
browsers dan errores, Al hacer la imagen 
original más pequeña debemos tener en cuenta 

Figura 3. 



que esta operación debe realizarse antes de 
disminuir el número de colores. Es decir, 
primero cambiaremos la escala de la imagen a 
24 bits de color y luego procederemos a 
disminuir el número de colores. Aunque en un 
principio pueda parecer que quedaría igual, el 
orden de los factores sí altera el producto, ya 
que en true color se realiza perfectamente el 
cambio de escala y en indexodo no. 

Otro aspecto a tener en cuenta es el color de 
fondo de la imagen antes de hacerlo 
transparente. Si la imagen de fondo de nuestra 
página es de tonos negros o grises (como la 
del ejemplo), deberemos construir nuestras 
imágenes sobre un fondo de tono gris oscuro. 

Figura 4. 
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Figura 5. 

Así, cuando fijemos un color como 
transparente, no se fugarán pixels de un color 
no deseado. 

En ei ejemplo de la página, hemos reducido el 
tamaño original de una imagen en formato 
semi-crudo (BMP) de 72 Kbytes a 3 Kbytes. 
Para ello hemos utilizado e! programa Paint' 
Shop Pro que se incluye en ei CD que 
acompaña a la revista. Cargamos la imagen 
original, y cambiamos la escala a 200x30 
pixels, ahorrando así la mitad de espacio en 
disco. Para ello iremos al menú ¡mage-resample 
y ahí indicaremos la dimensión a la que 
queremos reducir la imagen. Si tenemos 
seleccionada la opción Maintain Aspect Ratio 
tan sólo tendremos que modificar una de las 
dos dimensiones y la imagen no se deformará. 
Una vez realizado el cambio de escala, 
disminuiremos el número de colores y 
fijaremos un color como transparente. Para 
disminuir el número de colores, iremos a 
Colors-Decrease C olor Depth y reducimos a 16 
colores. ¿A cuántos colores debemos reducir la 
imagen? Pues al mínimo posible sin que la 
imagen pierda demasiada calidad. Todo es 
cuestión del diseñador. Aunque la imagen 
pierda un poco (no demasiado) deberemos 
sacrificar un poco de calidad y reducir así el 
tamaño de la imagen, los visitantes de nuestra 
web lo agradecerán. Tenemos la imagen a 16 
colores, ahora fijaremos un color como 
transparente. Iremos a Colors-Edit Palette, 
elegiremos el color de fondo de la imagen 
original (que era negro) y lo cambiaremos por 
un color chillón. Así tendremos la imagen con 
un fondo que destaque. Nos quedamos con el 
número de color que ocupa dentro de la 



Figura 6. 

paleta (en la misma ventana, abajo Palette 
índex). Ya tenemos la imagen lista para ser 
salvarla. Elegimos el formato GIF y pinchamos 
sobre Options-Set the transparence valué to 
palette entry, el número que hay que poner a 
continuación es el del color que hemos fijado 
antes como transparente, el número que 
ocupaba dentro de la paleta. En nuestro caso 
era el 0, Hecho esto, guardamos la imagen. 
Para incluir animaciones en nuestras páginas, 
como hemos indicado antes, debemos utilizar 
el formato GIF. En el mercado hay una extensa 
gama de programas para construir GIFs 
animados. Uno de ios más sencillos de utilizar 
y muy potente es el GifMovie G ear, que 
incluimos en el CD de la revista. Insertaremos 
los distintos fotogramas que componen una 



Figura 7. 

animación uno por uno. Para ello, iremos al 
menú File/lnsert Frame y seleccionaremos las 
diferentes imágenes que compondrán la 
animación. Si no están colocados en el orden 
que deseas, bastará con que pinches sobre el 
trame descolocado y lo arrastres a la posición 
que necesitas. Una vez organizados todos los 
trames, indicaremos el tiempo de espera que 
habrá detrás de cada uno de ellos. Bastará con 
que pinchemos (para seleccionar) sobre cada 
trame, y pongamos el tiempo en el recuadro 
que hay al lado del reloj del menú superior. 
Una vez ajustada la velocidad optimizaremos la 
animación. Reduciremos paletas ai máximo 
(siempre que no pierda demasiada calidad) y 
optimizaremos la animación (el programa lo 
hace automáticamente). Para ello iremos a 


Figura 8. 
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Figura 9. 


Para opciones de elección sencilla (tipo Sí o 
No), disponemos de «checkbox» 

<!NPUT TYPE=checkbox 

NAME= "DesarrolloYfuentes “ VALUE= "Sl"> 

En <VALUE> pondremos el texto que 
recibiremos en caso de que se active la caja. 
Otro tipo de entrada de datos es la persiana 
desplegable con varias opciones cuyo esquema 
general es el siguiente: 

<SELECT name=Opinión> 

<OPTION> 

<OPTION> 


Tools / Reduce Paiettes y a Pools / Optimize 
Animation respectivamente. La verdad es que 
no hay mucho que explicar sobre este 
programa, porque es bastante sencillo de 
utilizar y muy intuitivo. En una tarde, seguro 
que aprenderéis a sacarle el máximo partido. 

HAGAMOS UN EJEMPLO EN NETSCAPE 

Un formulario es muy útil en todas las webs. 
Así, los visitantes de nuestras páginas nos 
informarán de lo que más les gusta de la 
página o las partes que se pueden mejorar y, 
en general, sus gustos y preferencias. La 
elaboración de un formulario puede ser 
complicada, pero aquí os damos una forma 
sencilla y efectiva de elaborar vuestros propios 
formularios. Pondremos un ejemplo desde 
Netscape. Iremos a File/Edit Pagey 
comenzaremos con el diseño de nuestra 
página. Las zonas donde el visitante escribirá o 


realizará operaciones con ellas serán los HTML 
tags. No creemos que sea necesario explicar 
cómo se ha hecho todo el formulario. Lo mejor 
es que lo abráis (viene en el CD de la revista) y 
experimentéis con las distintas posibilidades. 

De todas formas, haremos un pequeño 
resumen: 

Para que nuestros visitantes incluyan datos 
como nombre, número de teléfono, profesión, 
etc., disponemos de un tipo de entrada 
denominada «fexf»: 

<INPUT TYPE=text NAME="Nombre" SiZE="50" 
MAXLENGTH=100> 

En <NA/WE> pondremos un identificador, 
<SIZE> será el tamaño del "cuadradito en 
blanco" que aparecerá en pantalla y 
con<MAXLENGTH> especificaremos la longitud 
máxima de texto que se podrá introducir. 


<OPTION> 

</SELECT> 

Y por último el área de texto libre, donde el 
usuario podrá escribir cualquier comentario, 
duda o sugerencia respecto de nuestra web. 

<TEXTAREA NAME=Xomentario" COLS=60 
ROWS-10 WRAP= "PHYSICAL "> 

} 

Como hemos comentado antes, la mejor forma 
de aprender es practicar con estos comandos y 
familiarizarnos con ellos. Por cierto, si pensáis 
utilizar d esquema de nuestro formulario, ¡no 
olvidéis cambiar el E-maÜ al que será enviado 
el formulario en el primer tagí 
Nada más por este mes. Nos vemos muy 
pronto con un curso de animación de 
personajes, técnicas y ejemplos. Hasta 
entonces, un saludo y a machacar pixels! 


Figura 10. 



Figura 11 ♦ 



Figura 12. 





















































































